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(57) ABSTRACT 

A method for updating a first version of installed application 
files to a second version is disclosed. The method comprises 
the steps of: responsive to receiving a delta file defining the 
changes between a file in the first version and a correspond- 
ing file in the second version, transforming said first version 
of the file into a first transformed image comprising a series 
of records. The changes contained in the delta file are then 
applied to selected records of the first transformed image to 
generate a transformed image of the second version. The 
transformation on the transformed image of said second 
version is then reversed to generate the second version of 
said file on said client computer. 

8 Claims, 2 Drawing Sheets 



Compiled from spin.java 

synchronized class spin eactends java.lang.Object 
/* ACC.SUPER bit set V 

{ 



void lookAtOateO; 
spinO; 
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Method void lookAtDateO 
OiconsLO 

I istofc.l 
2goto8 
5nicl 1 
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9t>tpush8 

II tfJcmpttS 
lA return 

Method spinO 
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4 return 
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class spin 
{ 

void lookAtDateO 
{ 

int i; 

// Date format 05/07/98 
for( 1=0; i < 8 ; i++ ) 
{ 

; // empty body 

} 

} 

} 

Figure 1 

class spin 
{ 

void lookAtDateO 
{ 

int i; 

// Date format 05/07/1998 
for( i=0; i < 10 ; i++ ) 

{ 

; // empty body 

} 

} 

^ Figure 3 
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Compiled from spin.java 

synchronized class spin extends java.lang.Object 
/* ACC.SUPER bit set */ 

{ 

void lookAtDateO; 
spinO; 

} 

Method void lookAtDateO 

0 iconst_0 

1 istore_l 

2 goto 8 
5 line 1 1 

8 iload^l 

9 bipush 8 
11 ifjcmpit 5 
14 return 

Method spinO 

0 aload_0 

1 invokespecial #3 <Method java.lang.ObjectO> 
4 return 

Figure 2 

15c 
9 bipush 10 



Figure 4 
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METHOD FOR DEPLOYMENT OF 
INCREMENTAL VERSIONS OF 
APPLICATIONS 

HELD OF THE INVENTION ^ 

The present invention relates to a method and component 
for deployment of incremental versions of applications. The 
method relates in particular to transferring Java class files 
across a network with greatly reduced data transfer. 

BACKGROUND OF THE INVENTION ^° 

Distributing only updates or patches for applications is 
common practice within the software industry. The benefits 
of only transmitting application files that have been updated, 
rather than an entire new version of an application are clear. ^5 

Prior art products available in this area include DRP from 
Marimba Inc. and WebDAV from Microsoft Corporation. 
ITiese products, however, concentrate on changes at the file 
level, i.e. the products check a previous version of an 
application against the current version and if a file has 20 
changed, it needs to be transmitted, if not then transmission 
is not required. It is then common, to further reduce the 
amount of information transmitted, for groups of changed 
files to be bundled together and compressed into for example 
a ZIP file or self-extracting executable file before distribu- 25 
tion. Class files for Internet appUcations can be bundled into 
Java Jar or Microsoft Cab (Cabinet) files for decompression 
before execution at a client computer. 

Client computers running Java applications downloaded 
from web servers across the Internet, typically keep Java 30 
applet classes in a local cache. It is sometimes necessary to 
update the cache to ensure the client is operating with the 
most recent version of the classes. Class files, by comparison 
to conventional appUcation files, for example for a Word 
Processor or Spreadsheet, are relatively small and even 35 
minor updates to Java applications could effect most of the 
classes. Thus, file based products such as the ones mentioned 
above provide little performance benefit to the user by only 
downloading changed files. 

The present invention allows software version migration 40 
updates to be downloaded to a client computer with a greatly 
reduced amount of data transfer from the code server to the 
client. 

DISCLOSURE OF THE INVENTION 

45 

Accordingly, the present invention provides a method for 
updating a first version of installed application files to a 
second version, said method comprising the steps of: 
responsive to receiving a delta file defining the changes 
between a file in said first version and a corresponding file 50 
in said second version, transforming said first version of said 
file into a first transfonned image comprising a series of 
records; applying the changes contained in said delta file to 
selected records of said first transformed image to generate 
a transfonned image of said second version; and reversing 55 
the transformation on the transformed image of said second 
version to generate said second version of said file on said 
client computer. 

The invention further provides a software component as 
claimed in claim 6. 60 

Whereas prior art techniques chunked updates at a whole 
class level when most version to version migrations involve 
a small percentage of change in the code base, the method 
according to the invention makes optimum use of already 
installed application objects on the client computer thus 65 
greatly reducing the amotmt of data necessary to download 
or transfer. 
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The downloaded data is the m inimum necessary delta file 
between the two class versions down to, for example, the 
Java Virtual Machine opcode level — this is likely to be much 
smaller than previous compression mechanisms and pro- 
vides a useful improvement in download time/bandwidth 
use especially with the emergence of non-trivial Internet 
applications (eg. Component Broker Java Objects, Enter- 
prise Java Beans.) 

The present invention also allows the free shipment or 
download of software updates to customers who already 
possess licensed versions of the software without requiring 
hcence verification or any special mechanism in the target 
software by using the previously purchased software as a 
kind of *key' necessary to use the available delta files. 

BRIEF DESCRIPTION OF THE DRAWINGS 

An embodiment of the invention will now be described 
with reference to the accompanying drawing, in which: 

FIG. 1 shows an extract of Java source code for a class 
file; 

FIG. 2 shows a flattened class file for the extract of FIG. 

1; 

FIG. 3 shows an update of the source code extract of FIG. 
1; and 

FIG. 4 shows a delta file generated for the files of FIGS. 
1 and 3. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

The preferred embodiment of the invention operates by 
flattening Java class (es) files for original and updated source 
code. FIG. 1 shows an extract from a simple piece of Java 
source code including a loop which iterates 8 times. FIG. 3 
shows this source code amended to cause the loop to iterate 
10 times. 

In the present embodiment a Java Development Kit (JDK) 
utility Javap is used to split the class file data stream of bytes 
for each source file into records, each of which represent one 
element of the Java class file. The flattened file for the class 
file corresponding to the source code of FIG. 1 is shown in 
FIG. 2. On line 9 of the method lookAtDate the record 
"bipush 8" has been generated. The flattened class file for the 
code of FIG. 3, only differs in that this line reads "bipush 
10". 

The two * flattened' classes are then compared using tools 
such as text comparison tools, for example, the UNIX "diff ' 
command. 

These tools (such as diff using the switch "-e") construct 
a delta file between two test files rapidly and output the delta 
information, preferably, in the form of batch editor 
commands, FIG. 4, that can be used to construct the new 
version of the text file, FIG. 3, from the original, FIG. 1. 

TypicaUy the delta file containing such editor commands 
is an order of magnitude smaller than the whole of the 
updated class file for a typical software version to version 
migration. Whereas conventional updates are * chunked' at 
the class level, with the present embodiment only the actual 
bytecodes that have been changed (plus a few other key 
bytes in the class file) need be commimicated — the smallest 
possible chunks. 

This delta class file of FIG. 4 is stored in the server to be 
pidled by the cfient (or possibly * pushed' to subscribed 
chents). 

On the client machine, the delta file is downloaded rather 
than the new version of the class. Tlien the original class file 
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is 'flattened*, the delta commands are applied and the 
resulting file is *unflattened* again producing a Java class file 
identical to the new version on the server in a greatly 
reduced overall time. 

A simple prototype for implementing the invention is ^ 
described below. "The Java Virtual Machine Specification" 
Javasoft/Addison Wesley describes the class file specifica- 
tion. A conventional type scanner, Javap, based on the 
grammar described in this specification processes the class 
files (FIGS. 1 and 3) into respective text files containing one 
terminal element per line, only the text file for FIG. 1 is 
shown in FIG. 2. 

It is acknowledged that Javap does not enable reversal of 
the flattening process. As such, if Javap type flattening is to 
be used, then a dedicated reverse utility, developed using 
conventional techniques, is provided. Alternative flattening 
utilities include the shareware Utility Mocha. Although 
Mocha provides flattening and reverse flattening, the flat- 
tened file includes more than one terminal element per line 
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any loss of content. AppUcations using the new class file can 
now be run as normal. 

It should be seen that a commercial embodiment would 
use customised equivalents of the above tools to achieve the 
same effect in one operation at the client machine. 

Preferably, the software for creating the update on the 
client machine could be built into a browser. This would 
operate in a similar manner to the way, for example, the 
"archive" switch operates with the HTML (Hyper Text 
Maric-up Language) "applet" tag so that classes downloaded 
as JAR files are automatically unjarred before being run on 
the client. 

It will be seen that, while the present embodiment is 
described in terms of Java, the invention is applicable to 
applications written in other languages. For example, the 
applications could also be written as a set of ActiveX 
Controls possibly with a visual builder such as Microsoft 
Visual Studio '97. ActiveX controls, however, can contain 
machine code with which the invention may not as effective. 
This is because in machine code inserting new code causes 



and so does not provide the same level of granularity for a lot of changes in subsequent code as a lot of the byte val^^^ 

. ^ ^ 1 are relative and absolute machine addresses and these 

detecting updates as Javap, . .r t *u u • * u 

^ ^ ^ change if the position of the machine mstructions changes 

inside the binary file. 

It is the tabular internal form of a Java class file that makes 



In any case, the UNIX 'difT tool with it*s -e option can be 
applied to the flattened file to create a delta file, FIG. 3. 
Equivalent tools are available both in other operating sys- 
tems such as "patch" on the AIX produced by IBM 
Corporation, or are used within conventional Revision Con- 
trol Systems (RCS) or Source Code Control Systems 
(SCCS). 

The delta file is then shipped to the client, in the present 
embodiment, across the Internet, 

The clients original class file corresponding to the source 
code of FIG. 1 is then flattened and broken into a text file as 
shown in FIG. 2, The delta file is then applied to the flattened 
file of FIG. 2, to change the original flattened file to the new 35 
one in one step, using, for example, the UNIX command: 
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(cat delta. file; echo *w')|ed — originalfile. class 



This command does the following: 

The "cat delta.file" prints out the delta file to what is 40 
termed the command pipe (or standard out). The PC equiva- 
lent is "type delta.file". The semi -colon indicates another 
command foUows.'echo' then prints out the string "w". This 
will just append the w or write command to the delta file. 
The * w' is an additional editor command that says (w)rite the 45 
file to disk — this saves the file back to disk. 

The *|' character 'pipes' the output command pipe of it's 
left hand side into the input of the command on it's right (ie 
ed — originalfile.class) This says 'batch edit the file origi- 



25 the binary codes more independent from their address posi- 
tion that makes this invention more useful with Java — as 
there can be changes to the code inside the class file (for 
example an addition of a new variable etc) that nonetheless 
will leave a high proportion of the values in the flattened file 
unchanged. Nonetheless, the invention is applicable to such 
apphcations in a similar manner to that for Java without 
departing fi-om the scope of the invention. 
What is claimed is: 

1. In a client computer, a method for updating a first 
version of installed appfication files to a second version, said 
method comprising the steps of: 

responsive to receiving a delta file defining the changes 
between a file in said first version and a corresponding 
file in said second version, transforming said first 
version of said file into a first transformed image 
comprising a series of records; 
applying the changes contained in said delta file to 
selected records of said first transformed image to 
generate a transformed image of said second version; 
and 

reversing the transformation on the transformed image of 
said second version to generate said second version of 
said file on said client computer. 

2. A method as claimed in claim 1 wherein said client 



nalfile.class and take further commands from the standard 50 computer is connected to a server across a network and said 



input — in the example the standard input is * piped in', as 
being 15c etc. as shown in FIG. 4 to give the new flattened 
class file. This file is exactly the same as the new flattened 
class file — but produced from the original and a smaller 
delta file. 

The embodiment then takes the flattened class file with 
it's machine instructions named to reconstitute the binary 
equivalent. 

It should also be seen that a commercial embodiment 



delta file is received across said network. 

3. A method as claimed in claim 2 wherein said network 
is the Internet and said application comprises a plurality of 
Java class files, 

55 4. A method as claimed in claim 3 in which said trans- 
forming step divides said class files into respective text files 
containing one terminal element per line, 

5. A method as claimed in claim 4 in which said delta file 
includes a plurality of batch editor commands, and said 



would have not need to make the flattened file of FIG. 2 so 60 applying step applies said commands to selected lines of 

human readable so each class file byte code could be said first transformed image to generate said transformed 

represented by a more compressed code rather than the image of said second version. 

code's 'name* (eg bipush) — so each delta line would be even 6. A component operable in a client computer for updating 

smaller than the example above. a first version of installed application files to a second 

The resulting flat class file is then unflattened by reversing 65 version, said component comprising: 

the original scanning and flattening process to produce the means, responsive to receiving a delta file defining the 

class file corresponding to the source code of FIG. 3 without changes between a file in said first version and a 
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correspoading file in said second version, adapted to 
transform said first version of said file into a first 
transformed image comprising a series of records; 

means adapted to apply the changes contained in said 
delta file to selected records of said first transformed 
image to generate a transformed image of said second 
version; and 

means adapted to reverse the transformation on the trans- 
formed image of said second version to generate said 
second version of said file on said chent computer. 



7. A web brow'ser for connecting a client computer to the 
Internet including the component of claim 6. 

8. A computer program product comprising computer 
program code stored on a computer readable storage 
medium for, when executed on a computer, updating a first 
version of installed application files to a second version, the 
product comprising a component as claimed in claim 6. 



